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AUTOMATION ORIENTED HEALTHCARE DELIVERY 
SYSTEM BASED ON MEDICAL SCRIPTING LANGUAGE 

DR YEONG KUANG OON 
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TEL: 03-97638935 
DATE:9 SEP 1998 

FffiLD OF THE INVENTION: AUTOMATION ORIENTED 
HEALTHCARE DELIVERY SYSTEM USING MEDICAL 
SCRIPTING LANGUAGE. 

Abstract 

This invention relates to automation of healthcare tasks delivered 
over a system installed on a local or wide area or network or 
intranet or internet computer network* This system and method is 
based on 1) a transportable human readable/machine parsable 
patient medical files or records coded in a medical scripting 
language with embeded executive commands for 2) a supervisory 
program with a transcendent medical belief system located at the 
server or client level, this supervisory program comprising means to 
interprete the medical scripting language and execute the embeded 
commands and 3)suitable patient file browsers ranging from 
standard Mosaic derived Internet browsers to a knowledge based 
medical spreadsheet ,to extend the spectrum of medical input and 
decision support in patient management to include all health 
workers and optionally the patient himself or herself. 

BACKGROUND OF THE INVENTION 

Good health is the concern of any global citizen. Computerization 
has the potential to help automate many aspects of healthcare; 
among them being automated recalls and reminders, what-if clinical 
problem solving and collaborative singular patient problem solving 
by a plurality of healthcare workers sharing a standard patient file 
that is functional across any computer operating system platform. 
Automation of healthcare is impaired by the lack of a viable 
universal transportable medical record that can fully encapsulate 
the total patient experience of all medical events and ongoing 
treatment and management of a patient. Patient's needs include 
prescriptive recalls for periodic health checks or management tasks 
based on specific disease diagnostic and management protocols. 
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In the internet era where knowledge is supposed to flow freely, 
modern medicine is incongruent in the sense that medical 
knowledge is packaged in a manner that is incomprehensible to 
most. The medical decision making based on scientific facts 
available to the practitioners is often a process that totally excludes 
the input of even the intelligent patient. This is in need of 
transformation. Modern medicine has often exalted the elitism of the 
medical profession and has in the main rejected or downgrades the 
possibility of the patient helping to diagnose and solve his own 
problems. This has at times progressed to the situation in some 
countries that any lack of patient fulfilment is translated to 
litigation. This has of course damaged the integrity of the medical 
profession where practice is now adapted to avoid litigation rather 
than providing best care. The cost of medical care is escalating in 
modern society for a number of reasons. Medicine has entered the 
phase of high technology with the proliferation of sophisticated 
laboratory and imaging tests with its attendant costs. With the 
plurality of service providers, it is economic from the healthcare 
budget and best in the patient interest to avoid duplication of tests. 
Also these medical tests should be done for the most optimal 
reasons. 

Increasingly the goal of modern medicine is evidence based 
medicine/best practice where the management is strictly set out in 
protocols with time components. An example of such a protocol is 
that regarding the management of diabetes mellitus. Nowadays the 
current best practice for management of diabetes mellitus requires 
1) initial referral to dietician and or diabetic educator 2) twice a 
year glycated hemoglobin (HbAlc) tests 3) annual review by 
opthamologist 4) yearly checks for microalbuminuria 5) yearly 
check by podiatrist 6) home glucometer checking. 

With increased societal affluence and educational level, citizens 
expect the best and optimal care. These factors conspire to drive up 
health costs. 

Aggravating the situation are 1) the existence of inefficiencies 
such as repeating unnecessary laboratory and imaging tests due to 
poor record keeping 2) drug to drug interactions 3) disease drug 
interactions 4)poor analysis of symptoms and signs from the 
viewpoint of insufficient physician time 5) restrictive work practice 
of the healthcare industry where the patient is locked out by an 
elitist medical profession: this often leads to a poorly informed 
patient 6) poor decision making that is tainted/driven by litigation 
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avoidance 7) ^^lack of a collaborative framework wherby all 
healthcare workers and the patient can together pool their resources 
to help fix the patient's problems 8) The recent phenomenon of 
patient queries arising from medical knowledge gleamed from 
dredging the internet, this is a natural desire by intelligent and often 
internet savvy patients to "manage" their own medical conditions. 

The doctor is challenged by the deluge of data generated by 
the practice of modern medicine; with the proliferation of tests and 
the need fortracking these tests, drug adverse reactions and 
interactions. There has been a veritable data explosion in the field of 
medicine associated with real advances in medicine. 



To recapitulate, the health problems faced by the care of the citizen 
patient are: 

1) patient's poor understanding of his own overall health 
problems, lack of knowledge tools to dissect his medical conditions. 

2) patient's poor understanding and lack of access to reliable 
recordal means of the sequence of events such as laboratory and 
radiological tests relating to his health problems, inability to access 
his own record on the internet or computer network. In an ideal 
situation, the patient has the means to log on his internet browser to 
find out his latest lipids results. 

3) patient is effectively disenfranchised from decision making based 
on scientific facts relating to his health problems from lack of an 
"independent machine expert" working on his medical status based 
on his medical record. Hitherto, there is no effective electronic 
transportable medical record framework for decision making. 

4) Attendant risks due to poor medical record keeping arising from 
fragmented nature of medical care by multiple carers over time and 
geographical spread resulting in fractured medical records. 

5) The lack of a write once, run anywhere computer medical record 
with built in embeded health protocol commands, regardless of 
computer platform. The absence of an effective transportable 
electronic medical record capable of fully representing patient status 
and ongoing management tasks based on concrete standards such as 
a text file of ASCII or even Latin-1 subset or UNICODE characters. 



6) Current art has medical records that are passive with data held 
in database fields, these data are aggregated/ searched/ processed 
and viewed by various data lenses. This passive structure of current 
electronic medical record design is contrasted with the need for 
patient records to include active executive commands, these set of 
commands would need to be individually tailored to each patient. 

7) With prior art, the record keeping computer program analyses 
every record to see if a record qualifies for action to undertake 
preventive action / initiate medical action - for example an adult 
woman is to seek a periodic pap smear and a periodic mammogram, 
a man over the age of 40 to get his blood pressure checked every 
year. Whereas in the invention detailed later, the patient file has 
embeded commands individually tailored for each patient, these 
individual commands will each will launch its own protocol. 

8) Poor coordination among a multitude of health providers. In an 
ideal situation, a health provider such as the family physician or 
specialist should be able to get an accurate run down on list of active 
problems, list of medications, lists of imaging and non-imaging test 
results and other related health information; this is to avoid the 
repetition of a test in ignorance of the fact that it was recently done. 
The ideal medical record must be able to provide "in a nutshell 
ability". 

9) Current implementation of electronic medical records held in a 
network is plagued by privacy constraints. In this invention, the 
concept of headerless anonymous patient files written in medical 
scripting language is proposed as a way to obviate the problem. 

10) Healthcare costs is aggravated by the time consuming nature of 
history taking and decision making. Significant cost savings can be 
derived if patient can present a list of properly defined and analysed 
symptoms during consultation with the doctor , a comprehensive 
medical history and management work sheet arrived at by the 
patient himself using the client spreadsheet browser, his file written 
in medical scripting language and interacting with the supervisory 
program detailed in this invention. 

11) With present electronic medical record systems, the consumer is 
locked out of viewing and having a say about his medical data, and 
is a passive element in the healthcare process. 
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12) A lack of a congruent set of patient data at the right palce and 
the right time. The pervasive internet fulfills the criteria of being 
online everywhere and every time as long as the network is up. The 
invention detailed below leverages on this fact and allows 
decisiveness at the moment of choice in healthcare. 

The ideal healthcare system must empower the patient In this 
internet age, the advance of educational level, the interest in health 
matters by consumers - there is potential for a win-win partnership 
between the patient and the collection of stakeholders in the delivery 
of healthcare. This invention discusses the framework and 
implemented steps that has to occur to bring this about. 

SUMMARY OF INVENTION 

This invention relates to automation of healthcare tasks delivered 
over a system installed on a local area network/wide area 
network/intranet/internet. This system and method is based on 1) a 
transportable human readable/machine parseable patient medical 
files/records coded in a medical scripting language with embeded 
executive commands, and comprising means for patient medical 
problem solving utilising knowledge spreadsheeting. 
2) a supervisory program with a transcendent medical belief system 
located at the server or client level, this supervisory program 
comprising means to interprete and execute the medical scripting 
language and 3)suitable patient file browsers ranging from 
standard Mosaic derived Internet browsers to a knowledge based 
medical spreadsheet to extend the spectrum of medical input and 
decision support in patient management to include all health 
workers and optionally the patient himself or herself. 
This machine augmented healthcare delivery system obviates the 
above stated problems in healthcare based on the just enumerated 
three components. 

A description of the three components follows: 

1) The medical scripting language is used to represent the patient 
file or record . The terms ^'patient file" and ^'patient record" are 
used interchangeably in this document A patient file may be stored 
as a computer text file or held as a very long string of characters in a 
single or more fields in a database system. Alternatively, a logical 
equivalent of a patient file is a persistent programming object. A 
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patient file written in medical scripting language integrates patient 
care by its means to represent every tiny medical event that has 
happened to the patient This file vi^ritten in medical scripting 
language is human readable, this implies the power of expressivity 
describing medical conditions that can approach the flexibility of 
natural language processing. Because- medical scripting language is 
constructed like a high level computer language, the patient medical 
file in this invention can be interpreted or compiled by a computer 
program. The structure of medical scripting language is defined in 
Extended Backus Naur Format, this same EBNF format is used to 
express high level computer languages such as Modula ( 
Programmig in Modula-2 by Niklaus Wirth , spronger Verlag 1982 ) 
and Smalltalk ( Smalltalk V , Digitalk corporation 1992). Medical 
scripting language is similar to say Java. Like any high level 
language, there are syntax rules and predefined keywords. The key 
difference between medical scripting language and say Java is that in 
Java there are approximately 48 keywords, whereas medical 
scripting language has in excess of twelve thousand keywords, with 
more to be defined. Each keyword in medical scripting language is 
a Docle expression. Docle is an alphabetic notational, coding and 
classification system used in clinical medicine. Medical scripting 
language is the glue that holds the disparate three components of the 
framework comprising the medical scripting language, the 
supervisory program and the patient browser together. The 
preferred future embodiment of this patient file is a computer file of 
the Unicode character set. The preferred current embodiment of this 
invention is with a subset of Unicode known as the ASCII character 
set, for the reason of compatibility with current keyboard design. 
The universally transportable medical record is coded in computer 
parsable, human readable medical scripting language and held as a 
string, based on the ASCII character set in this embodiment and 
possible future embodiments to include the complete Unicode 
character set. This patient file structure may be a computer field, a 
computer record, or a computer file or a programming object. This 
patient file represents patient status and includes means for 
embeded executive commands for invoking the supervisory program 
to run the designated protocols to effect healthcare actions. In short, 
MSL or medical scripting language is task-oriented. 

Representing a patient medical file in medical scripting language, 
and placing this file on a secured network ( or using the alternative 
option of headerless patient file in public networks ) such as the 



internet, opens all the health data pertaining to any individual 
patient for access, to the multiplicity of health workers, and 
optionally the patient himself. 

Representing the patient data in medical scripting language opens up 
the possibility of collaborative problem solving by the team of 
healthcare workers and could comprise the patient himself. 
Medical scripting language allows the inclusion of commands (with 
programming arguments) that will launch protocols that will effect 
health actions such as a reminder by email. 

Medical scripting language structures the patient file into sections 
that views the medical record as collection of time stamped 

1) administrative 2)commands 3)actions 4)Presentation-not yet 
defined data 5)Links- about to be defined data 6)Unity- well defined 
data and 7)management data. This scheme is a prerequisite and 
foundational for use of the patient medical file with a patient 
browser termed a medical spreadsheet or knowledge spreadsheet 
where the data have to be allocated to a plurality of cells. 
Medical scripting language allows the comprehensive coding and 
mapping of all medical entities held in the patient file, these allows 
for the decision support processing needed. In the preffered 
embodiment the patient medical scripting language file, the events 
are further tagged as negative, neutral, active or inactive. A 
summary abstract of his medical data comprising all global active 
medical events, global inactive events is a powerful enabling tool for 
the physician at any point in the globe to quickly evaluate a patient's 
general medical condition. 

2) The supervisory program has a built in transcendent medical 
belief system. Transcendant in the sense that the Docle coding and 
classification system codes for all medical objects and objects of all 
medical thought. The supervisory program can be located at the 
server or in special cases at the client level. This supervisory 
program comprises means to interprete and execute the patient file 
written in medical scripting language. Protocols or tasks are 
invoked by embeded commands held in the patient file. All patients 
are different, they require individually tailored protocols relating to 
their conditions. Only a diabetic patient requires a protocol to 
prompt for six monthly glycated hemoglobin tests. It is the role of 
the supervisory program to launch each protocol as nominated by 
the commands listed in the patient file. It is the role of the 
supervisory program to launch a drug-drug or disease drug 
interaction protocols each time the patient file is updated. 
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The supervisory program has built in protocols to act in the event of 
oversight to detect these drug-drug interactions and disease-drug 
interactions. The supervisory program has a built in medical belief 
system and can respond to enquiries from client browsers using a 
knowledge spreadsheet tool to effect what-if analyses. The 
supervisory program can respond to an internet client request with a 
patient file coded in HTML format to enable reading of the patient 
file using a standard internet Mosaic browser such as Netscape or 
Internet Explorer. Alternately the HTML document can be 
configured to include tables, picklist, buttons and controls to enable 
the web client to have a spreadsheet application on his web browser. 
Other embodiments of this framework has the web client running 
this medical spreadsheet application using Distributed Smalltalk, 
Java, JavaScript, Java Beans, Active-X,VB Script or any newer 
method of implementing client Server Web applications. 

3) The client patient file browser. 

A variety of browsers ranging from stock internet browsers to 
specialised medical knowledge spreadsheet to view the patient file 
can be used by healthcare personnel and the patient to interact with 
his patient file which represents the total database of his longitudinal 
health record. 

Any standard internet Mosaic browser such as Netscape or Internet 
Explorer will be able to view the patient file as the supervisory 
program comprises means to package the patient ASCII text file 
into HTML format. The browser has a utility to convert a ptient file 
in HTML format into a text file stripped off the HTML tags. Either 
way such a patient file can be viewed with a text editor such as 
Microsoft notepad. 

The specialised browser for this internet health system is a 
knowledge spreadsheet tool called a medical spreadsheet filed under 
the heading " Iterative problem solving technique " reference 
: PCT/AU97/00362 . 

The medical spreadsheet tool operates on the patient file encoded in 
medical scripting language. This spreadsheet tool is the preferred 
way for updating and interacting with the patient file. 

This invention uses the framework of the computer network in all 
its present and future embodiments can and will transform the art 
and science of medicine into a stable and viable system of quality 
medical care that is affordable and technically easy for citizens to 
adopt. 



In the preferred embodiment, the system is internet based. The 
patient files are held in an internet server with adequate firewall to 
ward off unwelcome instrusions. The supervisory program makes a 
daUy mark and sweep of all the patient files such that every single 
patient file is interpreted and any embeded commands executed. The 
result of such an execution of a command may result in an email 
reminder being sent to the patient and this action is logged and also 
sent to the primary care physician and medical specialists. 
Addressing the specific problems enumerated in the background 
section: 

This system and method for machine augmentation of healthcare 
will enhance and empower the patient with ready access to his 
medical record, such as to track his tests, and ability to manipulate 
it with a knowledge spreadsheet The invention proposes a 
transportable electronic patient suitable for a framework of problem 
solving and automatic triggering of health actions. The network 
oriented nature of the system comprises means for access across the 
globe. The patient file is a string of characters based on the ASCII/ 
Unicode standard, hence it should run on any platform. The patient 
file in medical scripting language is an active entity as it contains 
individually tailored prescriptive commands to invoke protocols in 
the supervisory program. The patient file held in a central server is 
the answer to duplication of tests. The headless patient files concept 
is one way to ameliorate the problem of privacy. The time 
consuming nature of medical analysis of symptoms/signs and clinical 
thinking can have its cycle shortened by the patient doing his 
homework on the medical spreadsheet and presenting to his clinician 
a more clearly defined reason for consultation - saving immense 
time. With optional patient access to his electronic file, integrity of 
his medical file is enhanced. The pervasiveness of his medical file in 
the intranet/internet embodiment allows integrity of decision 
making. 

B) Description of the Supervisory Program 

The supervisory pprogram comprises three components 

1) the Medical Scripting Language Interpreter and 

2) the protocol method 

3) the PLUM medical belief system and query language system 



l)The interpreter for the medical scripting language 
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The interpreter builds up a virtual image of the pa^^t by the use of 
dynamic data structures called OrderedCoUections. These 
OrderedCollections are named according to the categories of 
medical data of a) Administrative b) Commands c) Actions d) 
Presentation e) Links f) Unity g) Management The virtual image of 
the patient is constructed by populating these orderedCoUections 
with events held in the patient file coded in medical scripting 
language. 

Before the interpreter can execute the embeded commands held in 
the patient file, the patient virtual image needs to be build up first. 
The interpreter constructs the virtual patient image represented in 
the patient file by iterating through the following cycles. 

The state of the interpreter 

1) CurrentPatientName is a variable that holds the unique identifier 
to the patient file. 

2) EventMode is a variable that sets the indicator to direct where 
each event is to be placed in one of the orderedCoUections of events. 
2) The named orderedCoUections of a) Administrative 

b) Commands 

c) Actions 

d) Presentation 

e) Links 
f Unity 

g) Management 

1) locate the patient file 

2) open file or record 

3) while not at end, read next line comprising string of characters up 
to "WV token 

4) if at end of file, then close file and exit interpreter for now. 

5) Evaluate if change in the event mode. If so go back to 3. 

6) Add event to orderedCoUection set by EventMode. 

Having build up the virtual patient image, the interpreter now 
invokes the protocols as requested in the Commands 
OrderedCoUection. 



2) THE PROTOCOL METHOD 

The protocol method is implemented to signal to the patient or 
health worker the need to take a decisive health action such as 
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having the blood pressure checked, a pap smear, a cholesterol test 
The protocol parameters are 1) date when protocol command 2) 
periodic interval of preventive recall inserted 3) date of last action 
fulfilling action specified in protocol 4) date of last supervisory 
program recalling action such as email or mail out. 

In the Smalltalk embodiment of the program, all the protocols held 
inside the patient file is executed by the following program 
instruction: 

Commands do: [:x | self protocohx ] 

Where Commands is the orderedCoUection of command events. 
X is a local variable that instantiates to the value of each event as 
the do loop iterates through each element of the Command 
orderedCoUection. 

The protocohcommandString method 
A typical commandString is : 

12 Aug 1998 command@preventiveCare@diabetesMellitus%%365%30 

The variables and their role are: 
topic = the preventive recall activity 

activityPeriodicity = how often this preventive needs to happen 
repeatRecallFactor = how often the program needs to nag patient/doctor 
transpiredDaysActivity = number of days transpired since last preventive 
action 

transpiredDaysNotify = number of days transpired since last patient notification 
today := today's date 
lastNotify := date last notified 

The method uses the variables and determine their values as 

1) topic := preventiveCare@diabetesMellitus 

2) activityPeriod := 365 

3) repeatRecallFactor := 30 

4) activityPeriodicity = 36500 ? If true then quit protocol. 

5) transpiredDaysActivity := today - date last preventive event in Management. 

6) transpiredDaysActivity GREATER THAN activityPeriodicity? 

7) If true then calculate lastNotify := 

last action@ preventiveCare@diabetesMellitus in Actions . 

8) CALCUIiATE transpiredDaysNotify = today - lastNotify. 
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9) transpiredDaysNotify GREATER THAN repeatRecallFactor? ifTrue then 
email patient regarding need to see doctor regarding preventive action 
concerning diabetes mellitus. 



Extension of protocol method to include non health related matters 
such as birthday and other anniversary reminders and any 
reminders asscociated with social or business activities. Examples of 
useful reminders over internet email are i)Reminder to apply for a 
new passport one month before the expiry of one's passport. 
ii)Reminder to service the gas heater every three years. iii)Reminder 
to book a popular bayside holiday house in march for the Christmas 
holidays otherwise all accomodation would have been fully booked. 
This reminder system transcends the limitation of the constraint of a 
single year manual diary system. 

An example of a non-medical reminder is: 

12 Aug 1998 comniand@exceptionReport%'update your passport' %365%14 

The above reminder is for an example of a situation where the 
passport expires at the end of September 1999. This command will 
trigger an email to remind the patient/person to update his passport 
on the 12Aug 1999 and will do so at a frequency of forthnightly until 
the command is fulfilled by an equivalent action event: 

action@exceptionReport%'update your passport' 

Alternatively the command can be deleted when the event ha sbeen fulfilled. 



Technical Description of Medical Scripting Language Syntax 

The Syntax of the Medical Scripting Language is expressed in 
EBNF. 

This formal definition is based on Extended Backus Naur Formalism 

( EBNF is discussed in Programming in Modula 2 by Niklaus Wirth). 

EBNF Syntax rules are defined as: 

Syntax = { rule } 

rule = identifier expression 

expression = term { "|*' term }. 

term = factor { factor }. 



factor = identifier | string | expression | expression | 
expression 

MSL is a sequence of syntax rules. 

The right hand of each rule defines syntax based on previous rules 
and terminal symbols. 

Parentheses such as () group alternate terms. 

The vertical bar | separates alternate terms. 

Square brackets [ ] denote optional expressions. 

Braces { } denote expressions that may occurs zero or more times. 

A String is a sequence of characters enclosed in single or double 

quotes. 

An identifier is a sequence of letters or digits beginning with a letter. 

Example of a consultation defined in EBNF 

presentation = *cough' | *fever' | ^jaundice' | ^abdominal pain' . 
links = 'chest x ray abnormal'l 'ST elevation' | 'blood test abnormal', 
unity = 'pneumonia'! 'cold' | 'heart attack' 
management = 'reassurance'] 'penicillin' | 'bed rest'| 'linctus'] 
'patient education'. 

consultation = presentation [ links] unity ( 'reassurance' | 'patient 
education') management . 

An example of a consultation defined by above rules is 

cough fever 

chest X ray abnormal 

pneumonia 

reassurance 

penicillin 

Medical Scripting Language Syntax in EBNF 

MSL_file = header "\\\" { ("\\\" keywordToCoUection "\\\" {event "\\\" }) } "\\\" 
header = "docle_msl%'' string 

"id%" string 
"date%" date [ time ] [ "GMT" ] 
"server%'' string 
"content%'* text | html 
"contentLengthyo" digits 
"lastModified%" date [ time ] [ "GMT" ] 
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keywordToColIection = " #administrative " | "#command"^^#action" | 
"#presentation" | " #links" | "#uiiity'' | "#management" . 

event = date [ time ] docleExpression [ code%string ] [ imageLink ] comment [ 
accessionDetails ] [status] "\\\" 
date = dd mm yyyy . 
dd = 01 .. 31 

mm = "jan" | "Jan" | "feb" | "Feb" | "mar" | "Mar" | "apr" | "Apr" | "may" | 
"May" I "jun" | "Jun" | "jul" | "Jul" | "aug" | "Aug" | "sep" | "Sep" | 
"oct" I "Oct" I "nov" I "Nov" | "dec" | "Dec", 
yyyy = digit digit digit digit. 

digit = "0" I "1" I "2" I "3" I "4" | "5" | "6" | "7" | "8" | "9" . 
time = digit digit «:" digit digit [":" digit digit ] ["gmt"]. 
comment = { string} {"W" string}. 
packedString = { character | "_" | "-" }. 
string = { character | " " | "_" | "-" }. 
status = ++ I + I I- 

dodeOperators = "!" | "<*' | ">" | "%" | "@" | "#" | "$" | "%" | "^" | "&" | "*". 
letter = capitalLetter | "a" | "b" 1 "c" | «d" | "e" | "f ' 1 "g" | "h" | "I" | «j" | «k" | 
"1" I "m" I "n" I "o" I "p" I "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" | "y" | 



capitalLetter = "A" | "B" | "C" | «D" | "E" | "F" | "G" | "H" | "I" | "J" | 
"K" I "L" I "M" I "N" I "O" I "P" I "Q" I "R" I "S" | 
M-jiwi «u" I **V" I "W" I "X" I "Y" I "Z". 

character = | letter | digit | docleOperator. 

docleExpression = {character}. 

docleExpression ValueAdded = docleExpression "%" 

( docleExpression | packedString | "'" string 

" ' " ). 

imageLink = { http:www address | fileDirectory }. 

code = "icdlO" | "icd9" | "snomed" | "otherCodingScheme" 

command = "command®" docleExpression "%"[ string ] "%" digits "%" 

digits 

preventiveCode = "preventiveCare@" docleExpression 

action = "action®" docleExpression [ ("%" "email" | "mail" | "phone" | "fax" ) 
1. 



The Medical Scripting Language Environment 

There are currently defined seven special tags of the type 
keyToCoUection: 



#ad m inis trative 

#command 

#action 

#presentation 

blinks 

#unity 

#maiiagement 

These tags head up collections of events described by the 
keyToCoUection tags. 

The Patient file is comprised of events organised into these 
collections. 

Events are classified into the following types: 

1) adminstrative 

- these events deal with the administrative/office aspect of 
healthcare. Examples are 'medicare' , 'street' , 'suburb', 'state', 
'country', 'phone@home', email, 'phone@work', 'phone@mobiIe', 
'dob', 'maritar , 'upDate' 'markers', 'archive' , 'preferredDoctor' 
'pension' 'aka' 'surname' 'kin' 'workplace' 'sex' 'firstname' 'state' 
'warning' 'comment' 'zip') 

2) command 

The commands are used to invoke the supervisory program to the 
automate the protocols for 1) preventive health action 
2)immunization 3)regular periodic prescriptions and 4)any other 
periodic medical protocols. The outputs from the execution of these 
protocols result in recall messages such as in the form of emails, 
messages, a useful computer output or printed prescriptions to be 
issued. The command codes have the prefix 'command'. 
cominand@preventiveCare@diabetesMellitus 

cominand@preventiveCare@diabetesMellitus@consuItation@specialist@eye 
command@preveiitiveCare@diabetesMelIitus@hemoGIobin@gIycated 
cominand@preventiveCare@diabetesMeIlitus@eyeCheck%%365%60 ( repeat 
letter factor ) 

cominand@preventiveCare@lung 
cominand@preventiveCare@weight 

cominand@preventiveCare@akohol coinmand@preventiveCare@osteoPorosis 
command@preventiveCare@colon cominand@preventiveCare@hyperTeiision 
cominand@immunisation@infl-uenza cominand@preventiveCare@cervix 
command@preventiveCare@breast 
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command@preventiveCare@cholesteroI 
coinmand@iininuiiisation@hepatitisB* 

command@preventiveCare@exceptionReport% 'abnormal 1ft* 
command@preveiitiveCare@prostate 
command@preventiveCare@skin 
command@immunisation@tetanus 

command@prescription%'digoxin(lanoxin),250mcg,l 24hi,100 rp2' %200%200 

The command@prescriptioii is a powerful command in the sense 
that it automates the regular periodic prescription writing of a 
patient's medications. The command would trigger the preprinting 
of prescription scripts so that these scripts may be picked up the 
patient subsequently. 

3) action 

Arising from the execution of the commands held in the MSL file, 
preventive actions such as generation of a reminder via letter or 
email, these actions are recorded as events, each of these events 
would carry a docle header with a word beginning with the word 
^action'. For each command has two numeric arguments, the first 
argument denotes the ideal interval in terms of number of days that 
the periodic health action should be carried out. The second numeric 
argument denotes the number of days that are allowed to lapse 
before another reminder is sent. 

The action type events are used to indicate to the protocol for 
preventive health action belonging to the supervisory program. 

action@preventiveCare@diabetesMellitus 

action@preventiveCare@diabetesMellitus@opthamoIogist 

action@preventiveCare@diabetesMellitus@hemoGlobin@glycated 

action@preventiveCare@Iung 

action@preventiveCare@weight 

action@preventiveCare@alcohoI 

action@preventiveCare@osteoPorosis 

action@preventiveCare@colon 

action@preventiveCare@hyperTension 

action@iminunisation@infl-uenza 

action@preventiveCare@cervix 

action@preventiveCare@breast 

action@preventiveCare@cholesterol 

action@iminunisation@hepatitisB 

action@preventiveCare@exceptionReport 

action@preventiveCare@prostate 
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action@preyentiveCare@skiii 
action@immumsation@tetanus 

The system and method of recall 

The system of recaU used is based on the mirroring the events in the 

following three OrderedCollections: Command, Management and 

Action. An example is the need for five yearly tetanus injections as 

prophylaxis of tetanus. In this instance, a tetanus shot has been given 

and a system of recall in five years is being set sup. 

The tetanus immunization shot leads to the following event being 

recorded in Management: 

8 Sep 1998 immunisation@tetanus 

This will clear all action@iminuiiisation@tetanus events in Action. 
The command event is: 

8 Sep 1998 command@immunisation@tetanus%%1825%30 

This command directive states that if the last immuni$ation@tetanus event is 
more than 5 years then action is to send off email reminder. 

Say 5 years from 8 sep 1998, that is around 8 Aug 2003, the supervisory program 
will interprete and execute the command line and find that the last 
immunisation@tetanus event is more than 1825 days old, an email will be sent 
off and the act of sending this email is recorded as the event below: 

8 Aug 2003 action@immunisation@tetanus. 

Say for example patient failed to respond to email reminder and no 
immunisation@tetanus was recorded, a second email will be sent 30 days later. 

It is possible to launch more drastic action if three identical consecutive action 
events pertaining to the same topic are ignored, such as triggering postal mail or 
being listed for personal phone contact. 



4) presentation type events are symptoms and signs of medicine 

5) links type events represent results both normal and abnormal 
arising from imaging and non-imaging investigations in medicine. 

6) unity events are well defined diagnoses in medicine, with defined 
prognostication and treatment in medicine. 



7) management describe the procedure and process of care in 
medicine and comprise drug, surgical and paramedical treatment 

The event encapsulates the smallest quantum of information that 
may be significant in the process of healthcare of the patient. 
The event is a string comprising the following substrings tokens 

1) The date token is of the format dd mmm yyyy 

2) an optional time of day token hh:mm:ss and time zone. 

3) a docle expression - e.g. diabetesMellitus 

4) a comment string in single quotes. 

5) an optional string held in square parentheses [ ] to denote date / 
author of event and electronic signature of person responsible for 
entering event. 

6) the last token of the event, a flag to denote 
active/inactive/log/suppress status of event . 

The operator % means has value , e.g. street%'121 borg st' 

The single backslash \ is a docle operator that means ^decreased by\ 

The double backslash W means a linefeed. 

The triple backslash \\\ is used as a delimiter of section keywords and 
events. 

The Docle coding system has over 14,000 docle expressions. 
Medical scripting language is like a programming language with 
14,000 reserved words. Medical scripting language is unusual in the 
sense that it is both a programming and a data file. Because of this 
programming aspect of the medical scripting file, healthcare actions 
can be initiated at the opportune moment to effect best patient 
outcome. 

Privacy considerations is a big issue in medical informatics. The 
medical scripting language comprises means with implemented 
steps of; 

have the patient file downloaded to a client in the network 
stripped off the administrative data or any obvious patient identifier, 
termed a headerless file, to ensure privacy of medical record; 

the patient identifier of this headerless file is a dynamic 
randomly computer generated number sequence known to both 
client and server, that is relevant only for the duration of the client 
computer session. 

Control of patient file size/ culling of events 



Automatic culling of events or compressing of changes is set by 
marking the status of an event as 'negative'. This is by using the - 
status flag just before the \\\ terminator for the event 
Action events that are over 2 years old may be deemed negative and 
transfer to archival storage to prevent overgrowth of patient file. 
Archiving and compaction of files are executed by the embeded 
command to cull the events: 

command@cull%%180% 

Like all commands, there are three arguments. The first argument is 
null, the second argument is 180 which means that the compaction is 
done half yearly. The third argument is null as there is no need to 
inform the patient that his file is being compacted. The supervisory 
program will delete all events that are termed 'negative* i.e. has a - 
marker just before the end of event marker \\\. 

Another useful command is to mark as negative those events that are 
prepared for culling: 

command@negate@actions%%180%735 

This above command will add a - sign at the end of each Action 
event that is 2 years old. This command will be executed every 180 
days. 

In one sense, the patient is like an actor, the physician is the director 
of the film script The patient has to put on the 'patient role' as he 
undergoes surgery, being experimented on with drugs, taking tests, 
being filmed in the radiology lab. The SCRIPT is the main thing 
otherwise the patient and the physician will all lose the plot The 
doctor keeps adding / amending the script when things turn awry. 
But the script keeps a fair record of what the actor (patient) and the 
director (the doctor) ought to be doing. 

The key to orderedCoUection tags are not necessary as the 
events headers (docle expressions) are already classified in the Docle 
medical belief system. Hence events can be reaggregated or merged. 
This redundancy provides safety for reconstruction of a medical 
record, repair of broken files, re -integration of files from a 
multitude of sources. 
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The medical scripting file is in ASCII Text format. The supervisory 
program can download to the client in plain text or in HTML 
format. 

Headerless MSL file is a strong method to confer security of privacy 
to patients. Headerless patient medical scripting language file is one 
where the events belonging to administration are suppressed. That 
way the medical events can be made public without prejudicing the 
privacy of the patient. 

SAMPLE MSL LISTING 29 aug 1998 

docle_msl%1.0 
id%97649788 

date%'27 aug 1998 09:03:07 GMT' 
server%docle.com.au 
content%text 
contentLength%1240 

IastModified%'5 jan 1998 19:08:17 GMT'\\\ 

\\\ #administrative \\\ 

18 jan 1998 medicare%'234567899' \\\ 

18 jan 1998 firstname% 'David' \\\ 

18 jan 1998 surname%'Oon' \\\ 

18 jan 1998 street%'29 Darryl Street' \\\ 

18 jan 1998 suburbVo'Scoresby' \\\ 

18 jan 1998 state% 'Victoria' \\\ 

18 jan 1998 zip%'3179' \\\ 

18 jan 1998 country %'Australia' \\\ 

18 jan 1998 phone@home%'97638935'\\\ 

18 jan 1998 phone@work% '9763841 1'\\\ 

18 jan 1998 phone@mobile%'04109887'\\\ 

18 jan 1998 email%' docle@compuserve.com' \\\ 

18 jan 1998 email@second%'oon@connect.com.au' \\\ 

18 jan 1998 dob%'18 jul 1953' \\\ 

18 jan 1998 marital%'married' \\\ 

18 jan 1998 preferredDoctor%'Dr Y K Oon' \\\ 

18 jan 1998 aka%'Bav' \\\ 

18 jan 1998 kin%'Juliet Kuang' \\\ 

18 jan 1998 workplace"/© 'Stillpoint Medical ' \\\ 

18 jan 1998 sex%'male' \\\ 

18 jan 1998 comment%' golfer bongo player' \\\ 
18 jan 1998 warning%' ' \\\ 



21 



\\\#command \\\. 

18 jan 1998 command@preventiveCare@diabetesM ellitus%365%30 \\\ 
18 jan 1998 

cominand@preventiveCare@diabetesMelIitus@consultation@specialist@eye%3 
65%60 \\\ 

18 jan 1998 

coinmand@preveiitiveCare@diabetesMelIitus@hemoGIobin@glycated%180%3 
0\\\ 

18 jan 1998 

coinmand@preventiveCare@diabetesMeUitus@eyeCheck%365%60 \\\ 

18 jan 1998 command@preventiveCare@lung%365%30 \\\ 
18 jan 1998 command@preventiveCare@weight%365%30 \\\ 
18 jan 1998 command@preventiveCare@alcohoI%365%30 \\\ 
18 jan 1998 command@preventiveCare@osteoPorosis%365%30 \\\ 
18 jan 1998 command@preventiveCare@colon%730%30 \\\ 
18 jan i998 command@preventiveCare@hyperTension%365%30 \\\ 
18 jan 1998 command@immuiiisation@infl-uenza%365%30 \\\ 
18 jan 1998 command@preventiveCare@cervix%36500%0 \\\ 
18 jan 1998 command@preventiveCare@breast%36500%0 \\\ 
18 jan 1998command@preventiveCare@choIesterol%365%30 \\\ 
18 jan 1998 command@immunisation@hepatitisB%1835%30 \\\ 
18 jan 1998 command@exceptioiiReport%'abnormal lft'%60%7 \\\ 
18 jan 1998 command@preventiveCare@prostate%365%30 \\\ 
18 jan 1998 command@preventiveCare@skin%365%30 \\\ 
18 jan 1998 command@immunisation@tetanus%1835%30 \\\ 
18 jan 1998 command® preventiveCare@warfarin%30%7 \\\ 



faction 

27 aug 1998 action@command@preventiveCare@diabetesMeUitus%email \\\ 
27 aug 1998 

action@command@preventiveCare@diabetesMellitus@consultation@specialist 
@eye%email \\\ 
27 aug 1998 

action@command@preventiveCare@diabetesMellitus@hemoGlobin@glycated 
%emaU \\\ 
27 aug 1998 

action@command@preventiveCare@diabetesMeIlitus@eyeCheck%email \\\ 



27 aug 1998 action@preventiveCare@lung%email \\\ 
27 aug 1998 action@preventiveCare@weight%inaiI \\\ 
27 aug 1998 action@preventiveCare@alcohol%email \\\ 

27 aug 1998 action@preventiveCare@coloii%emaiI \\\ 

27 aug 1998 action@preventiveCare@hyperTension%email \\\ 

27 aug 1998 action@immunisation@infl-ueiiza%einail \\\ 

1 may 98 actioD@preventiveCare@choIesteroI%email \\\ 
27 aug 1998 action@iminunisation@hepatitisB%email \\\ 

27 aug 1998 action@preventiveCare@exceptionReport%inaiI \\\ 
27 aug 1998 action@preventiveCare@prostate%email \\\ 

27 aug 1998 action@iminuiiisation@tetanus%email \\\ 

\\\ #preseiitation \\\ 

2 jan 1998 nose@discharge \\\ 
2 jan 1998 cough \\\ 

2 feb 1998 head@pain 6 hrs \\\ 

7 May 1998 sIeep@difficuItyGoingTo ++ \\\ 

7 May 1998 nausea \\\ 

7 May 1998 diarrhea \\\ 

7 May 1998 nausea \\\ 

7 May 1998 sleep@difficultyGoingTo ++ \\\ 

7 May 1998 diarrhea -H-XW 

27 Jul 1998 tiredness ++ \\\ 

27 Jul 1998 weight@loss 5 weeks ++ \\\ 

27 Jul 1998 appe-tite*l -H- \\\ 

27 Jul 1998 skin@pigmentation*h ++ \\\ 



\\\ #links \\\ 

27 Jul 1998 s@ferritin*l \\\ 
27 Jul 1998 s@glucose=%5.6 ++ \\\ 
27 Jul 1998 fullBloodExamination= \\\ 
27 Jul 1998 s@sodium*l ++ \\\ 



\\\#unity \\\ 

2 jan 1998 upperRespiratoryTractlnfection \\\ 

2 feb 1998 migraine \\\ 

7 May 1998 insomnia \\\ 

27 Jul 1998 hypo@natremia \\\ 



\\\ #management \\\ 

1 jul 1997 preventiveCare@hyperTension 120/80 \\\ 

2 jan 1998 amoxycillin@clavulanicAcid \\\ 

2 jan 1998 preventiveCare@hyperTension 120/80 \\\ 



2febl998 met^^pramide \\\ 

7 May 199iS preventiveCare@exceptioiiReport psa*h%8 \\\ 

27 Jul 1998 s@glucose \\\ 

27 Jul 1998 fulIBioodExamination \\\ \\\ 



THE MEDICAL SPREADSHEET BROWSER 
Overview 

The deluge of clinical data and the complexity of modem medicine creates stress 
all round. Unpleasant litigation can be a consequence of a system failure to track 
and evaluate the plethora of clinical events. Change and stress can be met by 
creativity in utilising machine intelligence, but machine intelligence can only be 
expressed by having as its input a representation of patient status and a 
representation of management protocols specific to the patient 
In this embodiment, the medical consultation is modulated by a piece of 
software called the medical spreadsheet browser. It is an event oriented medical 
record system that keeps track of and evaluate the ever increasing number of 
patient clinical events arising from modern medical investigations and clinical 
contact. 

The PLUM Medical Spreadsheet is a combination of the iterative problem 
solving method and a unique medical belief system built along the lines of the 
Linnean biological system and utilising multivalent logic. The construction of 
this medical belief system enables clinical expertise to be built up incrementally. 
The angle taken by the Plum medical spreadsheet is to use the spreadsheeting 
process as a recordal means during patient contact. Doctors can well, almost 
afford to forget all that they learnt in medical school! As at any stage of the 
consultation, a discrete query to the machine can be made. PLUM uses a 
plurality of data cells and the iterative problem solving method, characteristic of 
the spreadsheet. The name PLUM is an acronym for Presentation Links Unity 
and Management, which is the health model used in the medical spreadsheet. 

The typical accounting spreadsheet is a number cruncher and gives the 
accountant quick answers to "What if?" type queries. The results of this "What 
if?" analysis are placed in the spreadsheet cells; this sets up the conditions for 
the next round of calculations with no manual transcription. The accountant's 
electronic spreadsheet is prodigious for tasks that require repetitive work with a 
hand held calculator. Hitherto, there is no such equivalent spreadsheet in either 
the medical or legal domains. With PLUM, during a client encounter, there is the 
capability of : 

• allowing data entry and recording 

• performing "What if?" calculations pertaining to client diagnosis and 
management, with the results placed in cells for the next round of evaluation and 

• features such as scrollable worksheets which can be saved. 

PLUM is used in a real or simulated patient or client encounter environment. 
During a patient encounter, the clinician needs to record the clinical details and 
constantly makes evaluations of clinical problems, resulting in treatment in the 



event of a diagnosis, in the event that no diagnosis is made,^^her investigations 
are instigated. PLUM facilitates the recording of clinical data while at the same 
time using the same worksheet to provide computer evaluation of clinical status 
with resultant guidance regarding problem analysis, investigations and 
treatment. The motivation of PLUM is to introduce the spreadsheet metaphor 
into clinical medicine. There were at least two main barriers that needed to be 
surmounted to attain such an invention. The. first was coming up with a 
replacement for the number system used in conventional spreadsheets. PLUM 
uses a word-based coding and medical belief system modelled on the Linnean 
classification. In this system a medical condition such as gout is a medical species 
with its own phylum, class, order, family and genus. Surmounting the second 
barrier was finding a suitable homogenous clinical data model of patient health 
status at the local encounter and the global level. 

The traditional model of the encounter is called SOAP for Subjective 
(symptoms), Objective ( physical signs ), Assessment (what the doctor thinks of 
the whole consultation) and Plan of management. In the old medical model, the 
patient global status is a list of active/inactive problems. The homogenous model 
used by PLUM is the Graduated Discrete Definition Model which allows the 
clinical encounter data to be viewed in the same framework as the patient global 
status. This new model overcomes all the shortcomings of the traditional medical 
record where the encounter is disjointed from the patient global status. PLUM 
provides the clinician with a spreadsheet tool for use in patient care to effect 
efficient diagnosis, management and data recording. There is also a paper 
equivalent to the medical spreadsheet which forms the basis of an effective 
manual/hybrid medical record system. The input and output of the medical 
spreadsheet process are based on the cells of the spreadsheet during a real or 
virtual patient encounter. As the input and output arising from the patient 
evaluation are all cell based, this provides the powerful paradigm of iterative and 
hypothetical type problem solving. Applying the same spreadsheet metaphor, the 
pages (or worksheets) of this medical spreadsheet can be scrolled back and forth 
and get saved for future reference. This clinical data model used in the medical 
spreadsheet supports a logical framework for the recording of the clinical 
encounter and displays cumulative patient data in the same format as the clinical 
encounter. In this Graduated Discrete Definition Model, the classification of all 
clinical data uses one main criterion, which is the degree of definition of a clinical 
datum in terms of readiness for medical treatment and/or prognostication. 

With such a classification framework, at one end of the scale there would 
be the not yet defined clinical data such as a clinical symptom or sign; these 
clinical data items do not have the degree of definition necessary for treatment or 
prognostication. At the other end of the spectrum, we have the well defined 
clinical data such as a diagnosis which has a clear prognosis and treatment. 
There can be one or more intermediate categories positioned between the not yet 
defined and the well defined categories. The preferred option of PLUM is an 
intermediate category called the about to be defined category. To complete this 
classification model, there is an additional category to include all extrinsic 
patient clinical data comprising treatment and investigations. The tetrad version 
of the Graduated Discrete Definition Model is called PLUM. All clinical data to 
describe the patient status and patient management is classified into the four 
categories of : 
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• Presentation - ims comprises all not yet defined clinical data such as symptoms 
and signs 

• Links - this comprises all about to be defined clinical data such as the abnormal 
test results and provisional diagnoses made by the doctor; these entities are not 
specific enough for treatment and/or prognosticati n but better defined as 
compared with the not yet defined data 

• Unity - this comprises all well defined clinical data of the clear diagnosis type 
where there is specific treatment and/or prognostication 

• Management - this comprises laboratory and radiological investigations, drug 
treatment, procedures and process of care. 

PLUM represents the four categories of the tetrad version of the Graduated 
Discrete Definition Model. The clinical encounter form has four cells, 
representing the four categories of PLUM. The Presentation cell is reserved for 
not yet defined clinical data. The Links cell is reserved for about to be defined 
clinical data. The Unity cell is reserved for well defined clinical data. The 
Management cell is for clinical data related to treatment and investigations. The 
PLUM model provides the framework for the spreadsheet The Graduated 
Discrete Definition Model, of which PLUM is the tetrad implementation, is 
congruent with the underlying logic of the doctoring process, which is the 
processing of unclear clinical information to resolution in the form of a well- 
defined diagnosis. This is followed up with treatment, or investigation if 
resolution is not possible. The ^What-if?^' query is launched from the drop down 
menu, of which there is a choice of over 50 useful types out of a possible 225 
basic permutations. Typical queries of the medical spreadsheet would be: 



•given symptoms and signs, show possible diagnoses 

•given a set of possible diagnoses, symptoms, signs and laboratory test results, 
show only diagnoses that conform to available data 

•given a list of diagnoses, show diagnosis that can unite several diagnoses. 

After each computer-assisted evaluation, the worksheet is updated and the 
worksheet page number is incremented by one. The PLUM worksheet on the 
screen is called a page, it depicts a real or hypothetical image of the patient status 
and can be saved and recalled. 

Another useful feature of PLUM is by clicking on the HOT KEY, this function 
evaluates all Presentation items, makes a list of differential diagnoses, from the 
list of differential diagnoses proposes a weighted list of symptoms and signs to 
ask/look for. 



Docle Systems stumbled onto the PLUM Medical Spreadsheet almost by default 
It is the originator of the Linnean Docle medical coding system used by over 5000 
medical practitioners Australia-wide. It was the congruent classification of 
disease entities, akin to the building of a belief system framework that allowed 
the medical belief system to be viewed using the spreadsheet metaphor. PLUM is 
relevant to any problem domain where the problem s Iver needs to arrive at a 



diagnosis given a set of indeterminate data. The knowledge^Rnain that almost 
mimics the medical domain is the legal field, and an equivalent theory for legal 
problem solving in the spreadsheet form also exists (patent pending). PLUM 
represents a new class of software - non-numerical spreadsheets. 

Technical Description of the Medical Spreadsheet Browser as a Web Application 

To start the medical spreadsheet browser: 

1. Start the web browser. This may be Mosaic, Netscape or Internet Explorer. 

2. Using the web browser, request the following URL: 

http://www.hostMachine/Iaunch/plumSpreadsheet 

3. The browser sends the request to the server hostMachine. 

4. The hostMachine uses default resolvers, the path 'launch' will cause the 
execution of the program plumSpreadsheet on the host machine. In this 
embodiment, an instance of class plumSpreadsheet, a user interface session of 
the medical spreadsheet, is created. Sessions make possible for multiple users to 
have concurrent use of the server supervisory program. 

5. The server will seek verification of user and password. 

6. The patient file written in medical scripting language is retrieved. 

7. The plumSpreadsheet session main menu will have choices for global log, 
global inactive or global active displays, an encounter spreadsheet form, save 
and cancel buttons. 

S.Say the plumSpreadsheet encounter is chosen, session will then instead of 
splashing a screen with a plurality of cells on the screen and a pick list, converts 
the panes and text into a hypertext Markup Language (HTML) document which 
is despatched to the browser for display. 

9) After entries are made in the Presentation, Links, Unity or Management 
panes, then if one of the queries is acivated then a submit request and the data 
in the spreadsheet in the cells is then despatched from the client browser to the 
supervisory program. 

10) The supervisory program evaluates the spreadsheet query, produces an 
appropriate response and then despatch the answer back in HTML format to the 
client. 

11) Go to 9. 



The Docle coding classification and medical belief system. 

Any medical decision support system, from the most rudimentary to an encompassing 
system, requires a belief system comprising of a basic set of assmnptions. Based on 
this premise, one cannot achieve a useful global decision support system 
encompassing the fields of medical history taking, physical examination, 
investigations, diagnoses, surgical treatment and drug therapy - unless a general 
medical belief system is constructed that spans across all the domains mentioned. This 
presentation describes a coding, classification and general medical belief system that 
spans and embraces two separately defined fields of endeavoxir in medical informatics 
today. On one end of the spectrum, there is the field of endeavour relating to medical 
coding and standardisation of terminology. To the other end of the spectrum, the field 
of endeavour is the construction of medical decision support systems utilising IF- 
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THEN rules or similar AI techniques. The schism between coding and knowledge 
representation has resulted in a situation akin to the architect using drawings to 
represent his designs while the builder is using a text description to build the house. 
The alphabetic Docle system unifies coding, classification and knowledge 
representation. Docle is different, the coding part being the mere keys to the medical 
belief system. Medical entities are classified as species and placed in a Linnean 
hierarchy much like a species such as Homo Sapiens. For instance, the liver object at 
the level called ORDER, knows all its associated diseases, symptoms and signs. So 
what is the big deal? A coding cum classification cum medical belief system appears 
to be an efficient approach for the construction of decision support computer 
programs - and may well save years of hack work for the implementor. 

The coding system for medical data is the "glue" that makes health informatics 
happens, without this proper "glue", projects will fall apart. Hitherto numeric coding 
systems such as ICPC and ICD are designed for epidemiologists and statisticians. The 
next wave in medical informatics is to encode medical data for day to day patient care, 
clinical decision support, transportable medical records and intelligent medical 
systems. These next wave projects have severely strained the old nimieric coding 
paradigm. Next wave coding schemes will likely to be alphabetic and will incorporate 
attributes of medical belief systems. A code for a symptom will be linked to 
associated organs. The Docle coding system is used by more than 2000 medical 
practitioners in Australia, making it the most used coding system in general practice 
in Australia today. The classification system comprises the following phyla or 
chapters: disease diagnoses, symptoms, signs, reasons for encoimter, diagnostic 
imaging, diagnostic non-imaging, treatment procedures, and therapeutics. The Docle 
coding and classification system has been designed to solve the following problems 
1) a coding system in medical informatics 2) a method to achieve standardization of 
medical abbreviations 3) a medical belief system that parallels the Linnean model m 
biology suitable for the organization of medical knowledge and 4) a medical belief 
system suitable for the design and implementation of sophisticated medical decision 
support systems. The Docle health classification system has drawn the two strands of 
biology and medicine together in that they follow the Linnean model of classification. 

How is Docle different from today's numeric coding system? 
1) Variable versus computer constants 

One of the biggest differences between Docle and the prior art of Read, ICD, 
SNOMED and ICPC is that Docle uses the computer variable concept while the rest 
of the field are implemented like computer constants. A variable is like a container. 
This container in Docle, called a Docle object, can be accessed via primary, secondary 
and tertiary keys. The three types of keys are equivalent in the sense that they all point 
to the same container with its stored methods and data. Inside the container is the 
'belief system' about the object. While the name of the variable is fixed, the contents 
of the variable may vary over time. The variable may contain a pouiter to another 
variable and ad mfinitum. The variable defined may be a huge data stmcture, itself 
may hold assorted variables and constants. Such a dynamic design gives maximum 
flexibility to cope with changes. As opposed to this framework, one can use the old 
method of say item 222 maps to diabetes mellitus or a slight modification such as 
LK222 where L implies it is a symptom and K implies cardiovascular. Any 



classification based on symbolic constants will suffer the ravage^of atherosclerosis. 
Docle makes use of the concept of separation of the belief system data from the key 
code itself This deferment of data binding to the code key provides Docle with 
xinparalleled flexibility to expand and mutate with the growth of medical knowledge. 
The key, be it primary, secondary or tertiary (see later) - all leads to the same medical 
object with its stored behaviour. Medical advance will lead to gradual adjustments to 
the behaviour of the medical object. It is hard to envisage the need to change species 
names such as rheumatoidArthritis or diabetesMellitus. 



2) Number codes is not a viable belief system 

The Linnean System in biology is a viable belief system that is alive, moving on with 
the advancement of biological knowledge. It is a framework or road map to the realm 
of biology. The gaps in the Linnean framework excites the imagination of the 
biologist about missing links in their knowledge. It is a powerftil method of cognating 
the knowledge that is being accumulated. This yearning for classifying and cognating 
medical knowledge was expressed in the preface of the ICD 9 manual, but it was just 
a yearning. Docle attempts to satisfy this yearning by tying the two strands of biology 
and medicine together. The docle classification system is modelled on the Linnean 
system, entities are described as medical species and medical genuses. Lists of 
numbers mapped to diseases are suitable for statistical analysis but will never excite 
the imagination of the medical researcher. 

3) Granularity problem and the Genus chunking solution. 

The granularity problem is familiar with anyone attempting to write a decision 
support program in medicine. An instance of this problem is the flagging of the 
disease/drug interaction between the beta-blockers and diabetes mellitus. It would be 
tedious, inefficient and prone to error to try to pick up every specific type of beta- 
blocker interacting with every variation of diabetes mellitus. An example of the 
beneficial effects of chunking into genus level is the case of diabetes mellitus. 
Chunking up of the three variants of diabetesMellitus: diabetesMellitus@gestation, 
diabetesMellitus@insulinIndependentDiabetesMellitus, 
diabetesMellitus@nonInsulinDependentDiabetesMellitus 

into a genus called diabetesMellitus, allows the common behaviour to be stored in 
the diabetesMellitus genus object. Likewise we can chunk up the therapeutic species 
of propanolol, atenolol and metoprolol into the medical genxis betaBlocker. An 
adverse drug-disease interaction is flagged when the two genuses of betaBlocker and 
diabetesMellitus are combined. A new beta-blocker will inherit this interaction 
behaviour as soon as it is tagged as belonging to the genus of betaBlocker in its 
container holding its belief system. 

4) Why choke on number codes when Docle is a feast in verse? 

Up till now, SNOMED and all the predominantly numeric coding systems based on 
the the multiaxial concept had looked promising. With SNOMED and all its 
derivatives, as much information as possible is loaded into the code. An example is 
SNOMED coding for pulmonary tuberculosis with granuloma being T-2800 M-44060 
E-2001 F-03003. Another example of the relentless drive to pack as much 
information into its code as possible is the Read code, the code G301 1 stands for 
acute anteroseptal myocardial infarction. The G denotes the cardiovascular axis, the 3 
denotes ischaemic heart disease, the 0 denotes acute. The modem nxmieric codes such 
as Read and ICPC have been heavily influenced by the SNOMED technique of 
cramming as much information as possible in its code by using the multiaxial 
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technique. In practrce such a scheme goes awry as a condition could be both 
cardiovascular and infective, such as viral myocarditis. Such a scheme leads to a 
fixation on the codes rather than concentrating attention on the evaluation of the state 
of knowledge of the disease entities. It is like, we have got a space here in our number 
scheme, let us see if we can fit in any more entities. By then adopting the 
classification in vogue for a subspecialty, it is locked in a concrete code format. It 
may be effective for several years but leads to incongruities in the future as technology 
advances. With such a system, five years down the track you wish you had added an 
extra axis to cater for the explosion in knowledge about the genome. 

Another incongruity detected in the ICD9 coding system used in hospitals is 
the duplication of codes. Tuberculous meningitis can be viewed fi"om the tuberculosis 
angle or the meningitis angle, hence there are two different numeric codes 013.0 and 
320.4 describing the one and same entity. Such an incongruent event would not occur 
in Docle as the code/key for tuberculous meningitis leads to an object with inherited 
behaviour of tuberculosis and meningitis. The opportunity to save programming time 
in decision support construction is obvious. Instead of enumerating all the 
symptoms, signs and laboratory findings of tuberculous meningitis - one can cognate 
the belief systems of the tuberculosis and the meningitis objects, then overlay with the 
belief system data and methods unique only to tuberculosis meningitis. Docle is 
intuitive and suitable for a unified medical abbreviation standard, for example; 
carc.thyr means carcinoma located at thyroid. Currently there are 14,000 terms in the 
Docle dictionary, there are still 40,000 terms that are still unrecognisable in a 
feedback among the 100 respondents in the 2000 user group, these are mainly tertiary 
type keys which will be incorporated. Compared to the constant tinkering with the 
structure of Numeric systems, a word based system is comparatively stable and easy to 
maintain. The stability is derived from the fact that the docle term is a direct 
transcription of an entity that is real. The code diabm means diabetes mellitus, there 
is never a need to change codes. However the behaviour of the diabm object needs 
tinkering with the evolution of knowledge 

5) Code shear technology. 

Docle is built up of words joined by operators, much like an internet address. Coded 
entities are modified by aspects such as laterality, acute, chronic, simple, compound, 
complicated and male or female. The modifiers are added to the main code by 
clicking of buttons. The & character is the shear operator, an example is the code 
fracture.femur&rightHandSide&simple. During processing the substring 
&rightHandSide can be sheared off to return the basic code: fracture.femur . 

6) ^est Practice by stealth 

Evidence based medicine, world best practice - that is the catchcry of modem day 
practice. For the sake of efiBciency and wanting to conform to world's best practice, 
under Docle, best practice can be encoded inside the Docle object, each disease docle 
object can have a list of ranked recommended treaments and a list of ranked 
investigations. All these rapidly changing knowledge updated on the clinician 
desktop every three months. Adoption of a Docle type coding system will achieve 
Cochrane by stealth. 

Overview of the Docle Linnean Classification System 

The metamorphosis of Docle from a nomenclature to a classification system has been 
a slow evolution. The problem had been the false belief that diseases were properly 
classified by the ICD group under WHO auspices. While subspecialties have done 
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neat jobs in their little domains, there is no grand framework to^^hings together. 
Classification was initially deemed outside the problem domain that Docle was 
designed to solve. . Yet medical informatics has hit the wall with the lack of an 
efficient coding system, or as is generally thought. Is it a coding problem that we 
have? No one talks of assigning number codes to species of plants or animals. There 
does not appear to be a coding problem in biology. 

Then came the overwhelming realisation, that maybe it is not merely a coding 
problem. The "medical coding problem" has not been properly defined, hence the 
sometimes heroic solutions end up as astronomical flops. The problem is more 
profound than that. The problem is that a mature classification of diseases and related 
medical entities does not exist. Not one exists, as well developed and as disciplined 
as the biological classification system. We have failed miserably not coming up with 
a set of species names for disease entities. We have failed to define the concept of a 
medical species. There are no medical equivalents for the phylum, class, order, family 
and genus. There is no equivalent binomial nomenclature in Latin for rheumatoid 
arthritis or myocardial infarction. So instead of insisting on a genuine standard, like 
what the biologist got with his Latin binomial nomenclature, the medical fraternity has 
sold out for several long lists of number codes. These purport to cover a complete list 
of diseases, whose links to reality become tenuous with the passage of time. The lack 
of emphasis on species identification, and the attendant lack of standardisation of 
species names is of course due to the absence of a congruous framework. The rapid 
development of medical science and the critical lack of a decent classification 
framework for the medical field has resulted in a fragmented state of affairs. We have 
islands of information coded variously in SNOMED, ICD, Casemix/DRGs and ICPC. 
UMLS identified the problem, but instead became subsumed by it. 

Instead of coming up with more sets of numbers linked to medical entities, the 
challenge is to create an equivalent Linnean system. The proposed Docle framework 
is a classification system for the medical domain based on the Linnean model. We are 
not yet proposing Latin binomial nomenclature. It is unlikely the medical community 
will stomach the wholesale renaming of medical terms in Latin, not that it works. 
Classification by the direct transposition of the medical domain into the biological 
model of course does not work as the framework is not fiilly compatible. For that to 
happen, there are three prerequisites. Firstly we need the equivalent of the binomial 
nomenclature. This nomenclature must be a powerfiil and standard way of describing 
medical entities. Secondly, we need to completely rework the Linnean hierarchical 
levels and introduce new definitions for the various levels. Thirdly, we need to create 
new rules for the classification process. Instead of Latin names, we have a structured 
medical descriptive language called Docle. In the majority of cases, Docle names are 
names of medical entities that are straight out of the medical textbooks. Occasionally 
they may look like someone's internet addresses. These peculiar names are Docle 
expressions, first presented at the 1987 RACGP computer conference in Melbourne 
and subsequently at theAPAMI94, HIC95, HIC96 conferences. The epiphany for 
Docle happened in 1995 when it metamorphosed into a Linnean framework. For a 
more detailed discussion - see book published in 1995 and the HIC96 conference 
proceedings. 

The direction that Docle has taken is to use the concept of the species name as 
the KEY to a medical object, also called a Docle object. Hence Docle is a 
classification of medical objects. This classification of medica objects is also called 
Objects Medica. The medical object holds information that refers to memberships of 
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taxa, pointers to s^rcies in lower levels of hierarchy and its own level of hierarchy. 
That way as medical science progresses, the medical object is updated but the key 
remains stable. As there is no need to assign numbers to entities that are not nxmibers, 
species names are alphabetic. The problem is therefore straightforward 1) We have to 
identify all the species (or subspecies thereof) of medical objects 2) Assign to each 
species named, an object which is a data repository regarding its memberships of taxa 
and other information and 3) Classify them into a logical framework satisfying the 
requirements of all manner and types of health workers. This is important as previous 
coding systems were designed for the medical statisticians and certainly not for the 
information scientist who is developing applications such as a) for decision support in 
a clinical setting b) paperless medical records. 



The Docle Framework 

Nothing could be more logical than to borrow some ideas from the impressive 
edifice of biological classification started by Linnaeus in the 1 750s. One of the 
central tenets of biological classification is the concept of the species. The other 
tenets being the hierarchies and the concept of the taxon (plural taxa). A taxon is a 
group with shared values in each hierarchy. Species identification is half the work, 
while the other half involves placing the species in the right taxon in the right 
hierarchy. 

The system of classification in Docle is based on the above framework with 
major modifications. It would be fair to say that Docle is the ofifepring of Linnean 
classification and the object oriented language Smalltalk. Whilst the concepts 
discussed were first implemented in a computer system in Smalltalk, there is no 
problem whatever for Docle to be a manual system or written up in any standard 
database or high level computer language. 

The main deviations from the Linnean model are:- 

1) There are more hierarchies defined below the species level. There are the 
subspecies, subsubspecies subsubsubspecies and subsubsubsubspecies levels already 
defined. 

2) A species or any of its subclasses can have membership in any number of taxa at 
any level. This is the multiple inheritance feature of Docle. 

3) The corollary of the above is that a species may have no membership of any taxon 
at any level. 

4) As implemented in Docle, a taxon knows its membership. A species knows who 
its subspecies, subsubspecies, subsubsubspecies and subsubsubsubspecies are, if there 
is any. 

5) The taxa at the next level down of the hierarchy does not need to be descendants of 
a taxon at the current level. 

6) The entity to be classified is held in a Docle object (also referred to as medical 
object), the name of the object becomes the key to the object. There are three types of 
key to these Docle objects. The primary key is the complete key that can look like a 
textbook name or an expression that looks like an intemet address. Example of a 
primary key is diabetesMellitus. Note the absence of a space between diabetes and 



mellitus The secondary key is computer generated and is an ab^^iated version of 
the first using the Docle algorithm. Hence the secondary key is diabm. A secondary 
abbreviated key is -useful in that doctors like to communicate m a shorthand manner 
when possible. It is also a subtle method to get doctors to standardise on 
abbreviations. The tertiary keys are the nominated aliases of the entity. To 
summarise, in the case of diabetes mellitus, the primary key is diabetesMellitus; the 
secondary key is diabm and the tertiary keys are the aliases: diabetes, sugar diabetes. 
7) I have elected to use Americanised spelling. I am going to hear moans from the 
Commonwealth camps. Docle is about simplification, simplification and 
simplification. If it takes American spelling to make things simpler, we should 
simplify. Using American spellings add one more significant character to the Docle 
abbreviations. 



The hierarchies in Docle 

1 Kingdom - there is only one taxon located at this hierarchy. 

It is named Objects Medica. Objects Medica holds all medical objects and all objects 
of medical thought. 

2. Phylum - the taxa are: 

a) Medical Administration 

b) Symptoms Signs 

c) Diagnostic Non Imaging 

d) Diagnostic Imaging 

e) Procedures Process Of Care 

f) Therapeutics 

g) TAMTAP- (Thinking About Medical Thinking And Practice) 

h) Reason for encounter 
I) Clinical Domains 

3. Class - the taxa are the various clinical fields in medicine. 
The groups are Adolescent Health, Blood, Cardiovascular etc. 

4 Subclass -is reserved for the exciting frontier of genetic medicine. With the 
complete mapping of the human genome, gene locations/regions can be linked to 
specific medical syndromes. For example the HLA class H genes is linked to IDDM. 
We can use taxa such as a) X-linked b) Y-linked. We await a uniform nomenclature 
for gene maps. 

5 Order - the taxa are named anatomical locations and organs. 

6 Family - the taxa here are for the biochemical and physiological bases of disease. 
TTiis can be at the molecular and cellular level. Examples of the groups here are a) 
Disorders of lipid metabolism b) Disorders of the prostaglandins 

c) Disorders of nitrous oxide metabolism d) Disorders of heat regulation e) Disorders 
of the mucopolysaccharides f) Disorders of cell membrane transport. The subfamily 
hierarchy is reserved for taxa related to DRGs and Casemix. 

7 Genus - a taxon at this level is a larger concept and holds from 1 1 to 200 species. 
Examples of taxa are a) valvular heart disease b) arrythmia c) fractures d) bemgn 
neoplasm e) malignant neoplasm f) intermediate neoplasm. 

8 Superspecies - a taxon at this level is a concept that holds 2 to 10 species. 

An example of a superspecies is fracture of the femur. It is not specific enough for 
treatment and prognostication, it contains several species. 



9. Species - The root word is the Latin specere which means to look at. At the species 
level the medical entity is real and can be looked at or experienced by the 
patient/clinician. A species belonging to the phylum Clinical Domains is a 
characteristic syndrome with clinical features generally known. Often there is 
knowledge about its aetiology. There is knowledge regarding diagnosis by clinical 
and/or non-clinical methods. There exists in many cases a knowledge of its natural 
history. There is associated a system of management of this syndrome and in many 
cases methods of prevention. A diagnosis at the species level or better is required for 
specific therapy. Examples of a species are diabetesMellitus, fi-acture.femxir@neck 
and acidosis@metabolic. Species belonging to phyla other than Clinical Domain are 
non-abstract entities such as cough, chest X ray, or a swelling located at neck. 

10. subspecies - A diflferentiated type arising from species, it suggests more specific 
treatment and prognostication. 

1 1 . subsubspecies - A more differentiated type arising from subspecies. . 

12. subsubsubspecies - A differentiated type arising from subsubspecies. 

13. subsubsubsubspecies - A differentiated type arising from subsubsubspecies. 

14. subsubsubsubsubspecies 



A case study - classification of fractures involving the neck of femur. 

The primary keys are followed by its secondary keys. 

The production of these secondary keys are automated by the use of the Docle 



algorithm 

kingdom: object medica 

phyllimi: clinical domain 

class : musculoskeletal 

order: femur 

family: disorder of bone metabolism 

genus: fracture.femvu* - frac.femu, fracture - frac 

species: fracture.femur@neck - frac.femu@neck 

subspecies: fracture.femur@neck@pertrochanteric - frac.femu@neck@pert 



subsubspecies: fracture.femur@neck@pertrochanteric@avulsion - 

frac.femu@neck@pert@avul 

A Docle type solution to medical coding is inevitable if we use the evolution 
of computer languages as a paradigm. Computer programming moved from an 
instruction set of ones and zeroes to assembly language to high level languages and 
4GL. Likewise medical coding will jimip from mainly nimieric to alphabetic 
expressions. Docle is human readable and is more suited to input validation. For 
instance the dot operator means "located at", validation routines will make sure that 
the referred site is a valid anatomical one. Docle is human readable, hence it is more 
suited for mission critical tasks because the nurses and doctors can visually vet for the 
correctness of computer data. The concept of Docle keeps evolving and with time it 
will be obvious to the keen observer that Docle is a more logical system. History, 




logic and commonsense sometimes win in the long run. Technology cycles are 
fuelled by marginal increase in utility. The Docle codes are both human and machine 
readable, these codes are actually embedded in the case notes in the encounter form 
as implemented in the Event Oriented Medical Record (EOMR). The explosion of 
medical knowledge in the past twenty years has been phenomenal. There was no 
knowledge of HIV infection or the nitrous oxide mechanism in physiology back in 
1975. It must be puzzling to the biologists that the medical sector needs so many 
coding systems - SNOMED, ICPC, Read and ICD etc. The existence of multiple 
coding schemes is a hint that a sweeping simplifying solution is called for. UMLS has 
not lived up to its promise for a simple reason. Two wrongs do not make a right. 
With the changing pattern of health care delivery and a highly networked society, the 
advantages of a unitary system like Docle that can span across the various departments 
and specialities would be obvious. The statisticians can work at the genus level. The 
primary provider at the species level, the specialists and research scientists can work 
lower down at the subspecies or subsubspecies level. By the application of a human 
readable, character based primary Docle code, which the resident medical officer 
enters from a pick list in the patient electronic record - that piece of data capture by 
the resident medical officer or the staff nurse meets the data requirements for i) the 
day to day patient recording ii) medical decision support and iii) administrative 
purposes. 

A bit of trivia. All Docle objects are linked together to form a viable and congruous 
belief system. As an example of the congruity of the system, Docle has thrown up a 
previously unnamed body organ. Docle is fussy with its use of the dot operator and 
maps all body organs. It detected a gap in its anatomical hierarchy. The anatomical 
locations scrotmn and testis has a missing superclass, Docle has christened this organ 
the tistum. The docle for tistum is tist which has as its subclasses scrotum and testis. 
In one sense, Docle is the first medical coding system with balls. 



Conclusion 

The coding wars may be over, even before the first shots are fired. While government 
and quasi-governmental bodies trash out the merits or otherwise of the various 
medical coding systems, the goal posts regarding the ideal medical coding system 
have along with the computing juggernaut, inexorably moved forward. The internet 
standard called Common Gateway Interface (CGI) was accepted as an intemational 
standard, but overnight it became dated as Java and ActiveX were laxmched. Number 
based medical coding systems will probably go the way of CGI due to the relentless 
pursuit of quality and utility. And why not? 

Docle is a belief system modelled on the Linnean biological classification 
system. Medical entities are classified as species and placed in a hierarchy much like a 
species such as homo sapiens. Every one of the over ten thousand Docle medical 
objects are thus related in a congruous framework. For instance the liver object at the 
level called ORDER knows all its associated diseases, symptoms and signs. 




The true tension in medical informatics is not a coding battle but it is a war of 
the electronic and intellectual representations of the current medical belief system. 
The Docle health . classification system has drawn the two strands of biology and 
medicine together with the common Linnean model. The fundamental issue in 
medical coding and classification today is the same as the biological classification 
conundrum in the days of Carolus Linnaeus in the 1750s, the solution is to define (or 
in the case here revisit and annoint) the concept of the medical species, identify the 
said species and give them names. Then stick with the names until they are proven to 
be inaccurate. This will impart order in the medical informatics domain and may well 
save years of hack work for the medical software implementor. 



Claims 

1. A system and method for machine augmented healthcare 
delivery installed over a local, wide-area or internet network 
comprising 1) a supervisory program at the server, this program 
comprising components of medical belief system and interpreter for 
a medical scripting language for patient data representation; 2) a 
transportable patient medical file coded in a medical scripting 
language that is machine parsable and human readable; the patient 
file comprising means to represent patient status and means for 
embeded executive commands for the said supervisory program to 
effect healthcare actions; and 3) At the patient or healthcare worker 
client level, browsers ranging from a text based editor or standard 
Mosaic derived internet browsers, to a knowledge based medical 
spreadsheet that can be used to browse and operate on the patient 
file coded in medical scripting language. 

la The system and method of claim 1, comprises a medical belief 
system starting from a linnean classification of all medical species 
and subspecies, including steps of 

classifying each species into phylum, class, order, family, 
family and species; 

using a plurality of alphabetic keys to point to each medical 
object; 

creating a plurality of alphabetic keys by using operators to 
join basic word building blocks to form complex expressions. 



2. THE SUPERVISORY PROGRAM comprises implemented steps 
of: 



mark and sweep on a periodic basis whereby ever^^ingle patient 
file is processed at least once per sweep, the method comprising 
implemented computer steps of: 

opening and parsing each patient file written in medical scripting 
language; 

extracting all commands to be execute^ embeded in the patient file ; 
storing all presentation or symptoms or signs events in a data 
collection; 

storing all links or medical investigations result events in a data 
collection; 

storing all unity or diagnosis events in a data collection; 

storing all management or prescription or procedure events in a 

data collection; 

launching all the commands operating on the stored patient events 
data; 

comprising means to send off computer message to effect better 
healthcare of patient via email, voice mail, fax or print letter or using 
other communication modality to patient or/and healthcare 
workers. 



2. a The method of claim 2, whereby the preferred embodiment is for 
the supervisory program to do a mark and sweep on a daily basis 
whereby every single file is processed at least once per day. 

3. The transportable patient medical file written in medical scripting 
language comprising steps of: 

declaring the medical scripting language in Extended Backus 
Naur Format; 

representing the patient data file in a medical scripting 
language that is in human and computer readable format; 

representing the patient data file in a medical scripting 
language that comprises passive data elements and programmable 
commands to create dynamic alerting/recall actions; 
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represemmg the file as a character string with preferred 
embodiments in ASCII format or ISO Latin-1 subset of the 
Unicode character set or Unicode character set itself; 

deconstructing and reconstructing patient data into a data 
structure called an event; 

classifying and outputting each of these events into the 
categories of presentation, links, unity, management, administration, 
action and command; 

denoting each of these categories using keywords. 



3a The mehod of 3 , the medical file in medical scripting language 
comprising events with the implemented steps of : 

having each event to comprise the following components of a 
date/time header, a structured medical terminology descriptor that 
is humanly readable and defined for the computer interpreter, a 
comment field, a field for recording the signature of person making 
the entry or amendment, recordal means for accession details, and a 
field to denote the status of the event; 

the structured medical terminology descriptor may describe a 
presentation or links or unity or management or administrative 
data or a command for the supervisory program. 

the status of each event is denoted as a neutral log event or 
global active event or global inactive event or negative event to be 
archived or culled. 



3b. The method of claim 3, the medical scripting language comprises 
a structured medical language component that is human and 
computer parseable format and comprising the classification of 
medical entities such as symptoms , signs, diagnoses, treatment 
investigations and investigations results - in a linnean hierarchy , 
each entity has an alphabetic keyword mapping to a computer object 
which holds the belief system for the said medical entity ; 

each medical entity is further classified as either a presentation 
type for symptom or sign, a link type for investigation result, a unity 
type for diagnosis, a management type for drug treatment, an 
administration type for housekeeping and a command type for use 
in invoking protocols in the supervisory program. 
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3c The method of claim 3, comprising means for the patient file to 
be downloaded in HTML format to be viewed as a web page with a 
Mosaic type browser. 

3d The method of claim 3, comprising means for the patient file to 
be downloaded in ASCII character string format to be viewed as a 
document by a text editor. 

3e The method of claim 3, comprising steps for the patient file to 
have its events aggregated for administrative, command, action, 
presentation, links, unity and management items sorted in a 
chronological order. 

3f The method of claim 3, comprising steps for the structured 
medical language moeity to be associated with a value using the % 
operator. 

3g The method of 3 , the medical file in medical scripting language 
comprising means to represent a snapshot of the present and past 
patient medical status, comprising all relevant and significant 
medical information, comprisng all preventive protocols, comprisng 
all preventive protocols and the trace of all events arising from these 
protocols are held in one location as a file or record or virtual 
record. 

3h The method of 3, the medical file in medical scripting language 
comprising steps of aggregating events into not yet defined entities, 
about to be defined entities, well defined entities and management, 
providing the basis for medical problem solving utilising the 
spreadsheeting process. 

3h The method of 3, the medical scripting language comprises 
means to do reminders and recall, including the implemented steps 
of; 

establishing a framework for recall starting from three 
ordered Collections of command, action and management; 

starting from events in this framework the step of recall action 
is initiated; 

comprising means for command events to be user defined to 
extend utility of framework to do non-medical reminder work. 



3h The metho^^f 3, the medical scripting language comprises 
means with implemented steps of; 

have the patient file downloaded to a client in the network 
stripped off the administrative data or any obvious patient identifier, 
termed a headerless file, to ensure privacy of medical record; 

the patient identifier of this headerless file is a dynamic 
randomly computer generated number sequence known to both 
client and server, that is relevant only for the duration of the client 
computer session. 

4. The medical spreadsheet browser of the patient file written in 
medical scripting language comprises implemented steps of: 
requesting patient file written in medical scripting language from a 
network or internet server; 

opening and parsing each patient file written in medical scripting 
language; 

extracting all commands to be executed embeded in the patient file ; 

storing all presentation or symptoms or signs events in a data 

collection and displaying them on a computer pane; 

storing all links or medical investigations result events in a data 

collection and displaying them on a computer pane; 

storing all unity or diagnosis events in a data collection; 

storing all management or prescription or procedure events in a 

data collection and displaying them on a computer pane; 

and develops possible solutions within a framework of an 

interrelationship among preselected medical data ; 

and comprising means for scrolling and saving worksheets. 
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